Testing Without Requirements Specifications

By: Surbhi Shridhar

Test Cases: Introduction, Creating and Importance

Test cases have traditionally been used to test any system – software or otherwise. The test case may transform into a checklist, a comprehensive step by step guideline on information displayed by the system, or a simple black box scenario. In any case, a test case is a pure representation of what the system should and shouldn’t do.

A functional specification document on the other hand is documented the way the user would want the system to be or how he perceives the system to be. A typical functional system is dominated by user understandable language, screen shots and behavior. Business rules may also be documented as part of the document.

One can argue that it may be easier to test from a functional/requirements specification document than creating a separate test case document – since the basis of a test case document is the functional specification document.

However there are several known pitfalls with this approach. Some of them are - 1. Test scenario build up is difficult 2. Incomplete documentation of flows 3. Unit level approach rather than system level approach. 4. Business rules may not be apparent, though they are documented.

Typically a functional specification is the basis of developing test cases with user flows, business rules and special conditions thrown in.

Test cases without requirements specifications

On the fly development, pressurized deadlines, changing user requirements, legacy systems, large systems, varied requirements and many more are known influences for many a project manager to discard or not update the functional specification document. While a project manager/requirements manager may be aware of the system requirements, this can cause havoc for an independent test team.

More so, with ever expanding teams, temporary resources, a large system may not be documented well enough or sometimes not at all, for the tester to form complete scenarios from the functional specification (if present) document.

This can pose a great risk to the testing of the system. Requirements will never be clearly understood by the test team and the developers will adopt an ‘I am king’ attitude, citing incorrectly working functionality as the way the code or design is supposed to work. This can confuse end development and you may have a product on your hand that the business doesn’t relate to, the end users don’t understand and the testers can’t test.

Dealing with a system that needs to be tested without functional specifications requires good planning, smart understanding and good documentation - lack of which caused the problem in the first place.

Before I begin describing some ways in which you can tackle the problem – here are a few questions you could be asking yourself

1. What type of testing will be done on the system– unit / functional / performance / regression? 2. Is it a maintenance project or is it a new product? 3. From where have the developers achieved their understanding of the system? 4. Is there any kind of documentation other than functional specification? 5. Is there a business analyst or domain knowledge expert available? 6. Is an end user available? 7. Is there a priority on any part of the functionality of the system? 8. Are there known high-risk areas? 9. What is the level of expertise of the development team and the testing team? 10. Are there any domain experts within your test team? 11. Are there any known skill sets in your team? 12. Are you considering manual/automated testing?

All of the questions should help you identify the key areas for testing, the ignorable areas for testing, the strong and weak areas of your team. Once you ascertain the level of skills and expertise in your team, you have choices available to choose from. Depending on the comfort level in your team, you can choose one from the options given below.

Theoretical Approach

The theoretical approach will ensure that you have good comprehensive documents for the system at the end of the process. Use Case Based Approach

Traditionally use cases have been used for requirement gathering. There has been a considerable shift to use them for testing, primarily because they model user role-play, movement, access rights and the interaction of one module to another – which is essentially what a test plan aims to do.

A use case defines the following –

1. Primary actor or actors 2. Goal 3. Scenarios used 4. Conditions under which a scenario occurs 5. Scenario result (goal delivery or failure) 6. Alternative scenarios or flows

The advantage of this approach is that you have two ready things in your hand

1. Documented system functionality 2. Evident module interaction

The development or creation of the use case will not be an easy task. Typical way to develop a use case is to pick up the system screen by screen or module wise and talk to the concerned developers or business analysts. Users can also be brought into the discussion at a later stage. Most users will give you valuable inputs to the type of data they input to the system. That in turn can give you an insight to the flows of the system.

Exemplary questions that you can ask users/developers are:

1. Inputs to a screen 2. User movements/warnings on a screen 3. Access rights to screen(s) or modules. 4. Access to screen(s) and exits from screen(s) 5. Database checks/updates. 6. Outputs from a screen 7. Alternative inputs or exits from the screen(s).

You can screen these questions or add some based on the testing you will be conducting for the system. For e.g. If you are carrying out GUI testing, you could do well if you add questions like length of the text box (this question could be answered well by a developer, rather than a user or a business analyst). If you are doing system testing, you could probably cut out the question on database check or updates. On the other hand, if you are doing system testing as part of a technology migration, you should enforce that database updates are verified.

Business Rules testing

Every system operates on business rules. If one were to document the business rules on which a system is based – it would be an exhaustive list to write down and track. Most business rules become implicit in the design and mind.

Business rules are typically implemented separately from presentation, application and data logic. To add to this, they are under constant change due to market requirements, user needs and software upgrades. Business Rules testing will help validate that your system is performing as expected, thus enforcing correct business practices on the user and the system code.

A typical way to gather business rules for your system is by talking to the business analyst and trying to understand what the analyst expects the system to do or how he/she expects the system to behave. A meeting with a developer will be helpful to understand how he/she thinks the system should behave. You may get conflicting ideas here, and it is important that these are sorted out before you have begun testing.

You could document your learning using a spreadsheet designed as below. I have given some examples to help you understand what the header means.

The important point is to document all the business rules and at the same time understand the co-relation it has with various functional scenarios of the system.

You can expand the table above to suit your needs in order to understand the various normal and alternative flows of the system. Again, mould the table and the data that you gather to suit the type of testing that you will do for your system. If you are doing unit testing, you will use more business rules like the first example (min char length), than like the third example (available only if Option A..)

Keep the following in mind: 1. Divide the system into modules as done by development. 2. For each module, take views based on the kind of testing you intend to do. 3. Direct your questions to the right people. E.g. If you are unit testing a product, a developer would be the right person to talk to. If you are system or user testing a product, a business analyst or end user would be able to answer your questions. 4. If you are short on time, document your business rules in order of decreasing priority. 5. Be specific with your questions. Run through the product or the system yourself, and make a list of questions, before you attempt to ask other team members. 6. Know the difference between a business rule and UI design. For e.g. a warning message to indicate that all information may be deleted is not a business rule, but a UI design. 7. Check if the business rules are incorporated in the system as code logic or are stored in the database and are made use of through a rules engine. This will help you organize your questions better.

Walkthrough meeting with the Technical Specifications document

In a typical walkthrough, the author presents a code module or design component to the participants, describing what it does, how it is structured and performs its tasks, the logic flow, and its inputs and outputs.

This can be modulated to suit the needs of developing test cases. You can call for a walkthrough meeting with the business analyst, the head developer or the solution architect and request for a presentation of the system. If a technical specification (TS) document exists, it will do you good to do the walkthrough with the TS. The TS document will focus on the technicalities of the system, while the walkthrough will help you understand the front end of the system.

Document your system in the following areas at the time of walkthrough with the TS -

1. Working/Functionality of each screen 2. Special conditions/functionalities of the screen 3. Backend updates 4. Inputs 5. Outputs 6. Expected scenarios and results 7. Importance of the screen and its scenarios. 8. User interaction and dependency

Again, drill down to the level that your testing requires of you. DO NOT do the following 1. Convert the walkthrough to a problem solving session. 2. Try to find faults in the design, UI, system flow or layout. 3. Try to find faults in the DB design or architecture 4. Leave doubts till later. 5. Ignore glaring or critical faults. Point them out, but don’t attempt to find a solution.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/